For decades a number of software applications have, become core products used by professionals to manage various business operations. For instance, word processing, spreadsheet, document processing, presentation, and drawing software applications, such as Microsoft® Word, EXCEL®, PowerPoint®, Visio®, PROJECT, and Adobe® Acrobat®, have become ubiquitous in business and personal computer usage. Users create, edit, and otherwise manage their documents and other files within these applications. Thus, it these types of software applications are referred to herein parent applications.
Since their inception, parent applications have steadily gained popularity and now have become the foundation for most business and personal computing environments. As a result, third party applications were developed and designed to integrate with parent applications to provide additional features that compliment those of the parent applications. These applications, referred to herein as child applications, obtained functionality through their integration within a parent application or through user navigation from the child application to a location of a saved file created and/or edited in a parent application.
The diversity and growth of child applications has resulted in a computer programming environment where parent applications include multiple child applications that have been integrated within the parent application and expand the capability of the parent application. When a child application is integrated with a parent application, the functionality offered by the child application becomes available from within the parent application. The parent application may make the child functionality available through, for example, a button on a toolbar or through a menu option.
Because, however, the child applications depend on services provided by the parent application and may not work by themselves, the child applications must load when the parent application loads. For example, a business user's word processing document might be associated with a number of child applications, and thus, for example, include in its toolbar additional buttons relating to the various functionalities of the child applications. These functionalities may include functionalities to (1) compare the document to another; (2) convert the document to PDF, (3) format tables of contents and numbering; (4) add document identification numbers; (5) manage references and other footnotes included in the document; (6) enable robust image editing; (7) collaborate with other users; (8) manage externally designed templates; (9) integrate with a document management system; (10) track, manage and clean metadata; (11) conduct and manage screenshots; and (12) incorporate contacts from a contact management system. In scenarios where these twelve functionalities need to run, one user of a single parent application requires a minimum of twelve integrations. In addition, a minimum of twelve additional functionality buttons must be added to the interface of the word processing program, thus crowding the field of the word processing's preexisting traditional functionality buttons.
Integrating child applications in a parent application is typically done using the native application programming interface (API) provided by parent applications, such as COM objects, ODMA integrations, command line integration, DLL integration, or other known methodologies. Unfortunately, these multiple integrations create a computing environment that hinders productivity and causes major delays in the loading of the parent application because all the integrated child applications' integrations must also be loaded.
Regardless of the method used to create the integrations, the child application's integration resides within the parent application. Each time a user starts the parent application, the integrations, or “add ins” as they are commonly called, have to load and start. In addition, each time a user closes the parent application the “add ins” have to unload and stop. Thus, the greater the number of integrations, the longer the time the parent application takes to open or close, creating a loss of productivity for the users. Additionally, the integrated child applications open the parent application up to a range of potential errors, bugs, and other technical issues and conflicts caused by multiple child applications seeking integration with the parent application.
However, without “add ins,” accessing the functionality of a child application that is dependent upon a parent application requires multiple steps, leading to lost productivity. For example, a user wishing to compare two versions of the same PDF document, in a case where that comparison functionality is not integrated or “added in” as another functionality in the Word Processing software (e.g., Microsoft® WORD®), must first open the document comparison child application, then browse to and select the saved versions of the two files to compare and, finally, submit a request to process the comparison of those two files. Often the IT departments of company networks, frustrated by the problems and the consequential support burden created by “add ins,” remove them. The “add in” removal makes the users' workflow somewhat less productive.
Currently, there are only two options for dealing with the management and integration of child applications with parent applications. Users may accept the loading and unloading problems related to integrating “add ins” or remove the “add-ins” and accept the loss of productivity. Both of these are not ideal options to increase the productivity and efficiency of computer users. As such, current systems implementing child and parent applications are dated and have reached their capacity to improve productivity related to functionality and workflow efficiency.
Therefore it is desirable to provide users with the functionality offered by child applications without the inherent problems related to the current integration of those functionalities. Thus, there is a need for a method and system of software coupling that does not require child applications to integrate with and be presented inside of parent applications or require users to navigate through multiple steps to enable a child application to use files created in a parent application. Methods and systems consistent with the disclosed embodiments of the invention address these and other problems of current child application integrations.